ImmutaのABACとGlobal Subscription Policyを用いて特定のグループのユーザーだけにデータのアクセス権を付与してみた

モダンデータスタック(MDS)

#Immuta

#Snowflake

さがら

2023.08.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

さがらです。

ImmutaのABACとGlobal Subscription Policyを用いて特定のグループのユーザーだけにデータのアクセス権を付与してみたので、その内容を本記事でまとめてみます。

ABACとは

ABACとはAttribute-based access controlの略で、ユーザー、データなどに紐づく複数の属性(Attribute)の情報を元にデータアクセスを許可・制限するアプローチです。

Snowflakeなどでも採用されているRBAC(Role-based access control)は、１つのロールごとに固有の権限を持たせてアクセス権を管理する手法ですが、ユーザーの属性情報(部署・役職・etc)など複数の情報に基づいてアクセス権を管理しようとすると、１つのロールでアクセス権を管理することがつらくなってしまい多くのロールを作らなければいけないケースが発生しうると思います。

その点、Immutaで採用しているABACでは、ユーザーの属性情報、データのタグ、など複数の情報を用いてアクセス権の制御を行えるようになるため、より複雑なセキュリティ要件であってもロールをたくさん作ることが発生せず運用が楽になるメリットがあります。

ImmutaのABACについては以下の記事でも説明がされているため、こちらも併せてご覧ください。

Global Subscription Policyとは

Immutaでは「対象のデータソースをどのユーザーに見せるか」という条件をSubscription Policyとして定義しますが、Immutaで管理しているデータソース全体に適用されるSubscription Policyが「Global Subscription Policy」です。

Global Subscription Policyについて詳しくは下記のブログでまとめられていますので、実際にどのような条件で設定が出来るか知りたい場合はこちらのブログをご覧ください。

本検証で行うこと

組織の中にHRグループとSalesグループがあり、HRグループにしか見せたくないCOMPANY_EMPLOYEESテーブルがSnowflake上にあるとします。

ここで以下２名のユーザーについて、HRグループに属するIMMUTATEST_SAGARA2にだけCOMPANY_EMPLOYEESテーブルを見せることができるよう、Immuta上で設定をしてみます。

IMMUTATEST_SAGARA2：HRグループに属するため、COMPANY_EMPLOYEESテーブルを見せたい
IMMUTATEST_SAGARA3：Salesグループに属するため、COMPANY_EMPLOYEESテーブルを見せたくない

事前準備

Snowflake上でのユーザーの作成

まず今回の検証にあたり、連携先となるSnowflake上でユーザーIMMUTATEST_SAGARA2とIMMUTATEST_SAGARA3を作成しておきます。

この時点ではPUBLICロールしか付与されておらず、サンプルデータのDBしか見えない状態です。

Immuta上でのユーザーの作成

続いて、Immuta Accounts上でもIMMUTATEST_SAGARA2とIMMUTATEST_SAGARA3のメールアドレスを用いて、ユーザー作成しておく必要があります。

今回はAdd Multiple Usersを用いて下図のように作成しました。

この上で、使用するImmutaのインスタンス上でもこれらのユーザーを追加しておきます。Sync IAM Usersを押せば、新しく追加したユーザーをImmutaインスタンスに追加することが出来ます。

また、各ユーザーをImmutaインスタンスに追加した後、ImmutaとSnowflakeを紐付けるためにSnowflakeのUsernameを変更しておきます。

Immuta上のユーザーの画面から、左上の名前の横の点々を押し、Change Snowflake Usernameを押します。

ここで、SnowflakeのユーザーのProfileで確認できるUsernameを、表示されたポップアップのSnowflake Usernameに入力し、Saveを押します。

Immuta上でのGroupの定義

今回はImmutaのGroup機能を用いて、HRグループとSalesグループの作成を行います。

ImutaのPeopleメニューから、Groupsタブを押し、+ New Groupを押します。

Group NameやGroup Descriptionを入力し、Saveを押します。

続いて、+ Add Membersから対象のユーザーを追加します。

Search by Member Name or EmailからImmutatest sagara2を探し、選択します。下図の状態になっていれば、対象のグループにメンバーが追加された状態となっています。

同じ手順で、Salesグループを作成し、Immutatest sagara3を追加しておきます。作成後の対象グループの画面が下図になります。

参考：Groupに対するAttributesの定義

また、Groupに対してAttributesという形で属性情報を付与することが出来ます。

この機能を使うと、１つのGroupに対して別の属性情報を複数付与することが可能となり、後述するGlobal Subscription Policyの定義時にこのAttributesを用いて条件設定することも可能です。

複数Groupに共通する属性情報などがあれば、このAttributesを使うことでより効率よくGlobal Subscription Policyの定義ができそうですね。

Immuta上でデータソースにタグを紐付ける

続いて必須の設定ではないのですが、データソースに対してグループ毎のタグを設定すると今後もHRグループ専用のデータが作成されたときに自動的にアクセス権を付与することができるため、データソースに対するタグの紐づけを行っていきます。

タグの作成

まずはタグを作成するところからです。

ImmutaのGovernanceメニューから、Tagsタブを押し、+ Add Tagsを押します。

今回は部署に関するタグを作成するため、Enter tag nameのところにdepartmentと入れます。

続いてAdd Child Tagを押し、hrとsalesという部署名に当たるタグを追加します。同じ階層でタグを作りたい場合は、Add Sibling Tagを押せばOKです。

下図のように、departmentタグの子タグとしてhrとsalesができていればOKです。この状態になったらSaveを押せば、タグの作成は完了です。

タグをデータソースに紐付ける

続いて、作成したタグをデータソースに紐づけていきます。

対象となるCOMPANY_EMPOLOYEESテーブルの画面を開き、Overvuewタブで+ Add Tagsを押します。

Search by Tag Nameから、先程作成したdepartment.hrを探し、クリックします。

選択したら、Addを押します。これでデータソースへのタグの紐づけは完了です！

Global Subscription Policyの作成

これまでに定義したグループやタグの情報を用いて、どのユーザーにデータのアクセス権を付与するのかの条件を定義するGlobal Subscription Policyを作成していきます。

ImmutaのPoliciesメニューから、Subscription Policiesタブにおいて+ Add Subscription Policyを押します。

まず、What is the name of this policy?に作成するポリシーの名称を入力します。

続いて、How should this policy grant accesses?では作成したグループに属するユーザーにアクセス権を付与したいので、Allow users with specific groups/attributesを選択します。

すると、具体的にどのグループに対してアクセス権を付与する(Subscribeする)かの条件を定義するWho should be allowed to subscribe?が出てきます。

最上部のチェックボックスはCreate using plain languageのままにしておくことでGUいベースで条件の定義ができます。

次のAllow users to subscribe when userでは、select conditionでis a member of groupを選択します。これで特定のグループに属しているユーザーを対象と出来ます。

続いてsearch for groupでは、作成したグループであるsagara_hrを選択します。

また、Allow Data Source Discovery３つチェックボックスがあると思います。こちらのブログからの引用ですが、このような意味合いを持っていますので必要に応じてチェックしてください。

Allow Data Source Discovery
- 条件に該当しなくても、そのデータソース自体の表示は許可します（存在がわかる）。
Require Manual Subscription
- 条件に該当していても、サブスクリプションはユーザー側が手動で行う必要があります（Allow Anyoneの時のチェックボックスと同じ）。
Request Approval to Access
- 条件に該当しなくても、アクセスのリクエストを行うことができるようになります。
- この設定をONにする場合、リクエストが来た時の承認者を決める必要があります。

次の項目Should this policy always be required or share responsibility?ですが、これは対象のデータソースに対して複数のGlobal Subscription Policyが設定されている場合の挙動を決めることができます。

Always Required：他のGlobal Subscription Policyの条件も満たしていないと、対象のデータソースを見ることができません。
Share Responsibility：他のGlobal Subscription Policyの条件含め、１つでも条件を満たしていれば対象のデータソースを見ることができます。

最後のWhere should this policy be applied?ですが、このポリシーを適用するデータソースを決める設定です。

先程hrタグを設定したデータソースのみに絞り込みたいため、On data sourcesを押します。